In existing network environments, managing a client (e.g., a server, service, application program, or operating system component) involves managing configuration data stored on the client. In one example, a large number of different servers often host a variety of different services (e.g., web services, soap services, and/or operating system services). A server hosting a particular service usually stores thereon configuration data (e.g., software settings, operational parameters, service uniform resource locators (URLs), data retention policies, and site properties). Such configuration data defines an operation of the server in hosting the particular service. For example, the configuration data may determine an operational state of the server (i.e., whether the server is executing a service) as well as when and how a service is executed on the server.
As the network environment grows increasingly larger, managing or organizing a relationship among different clients and/or configuration data also becomes an increasingly complex task. For example, there may be a number of service classes, wherein a service class defines a set of services executable on a particular server (e.g., registration service and member center service may be part of the same service class). A group of servers may also be defined to execute one or more services belonging to a particular service class. Accordingly, servers belonging to this group of servers may share certain configuration data and other settings in order to provide a uniform and integrated service. As can be seen, managing configuration data (e.g., changing/overriding, adding/removing, and viewing the configuration data) across different server groups or service classes can be a challenging task.
In prior methods, managing configuration data involves manually managing the configuration data of a particular client. For example, in prior methods, an administrator would change configuration data by manually identifying one or more clients affected by a change in the configuration data and then manually updating the configuration data in the identified clients one by one. Such prior methods create substantial operational problems for network administrators. First, a large number of files, data access methods, and tools are frequently needed to manipulate configuration data across different clients. This results in a difficulty to track, schedule, and execute configuration data changes and requires a great understanding of the network environment in order to identify the affected clients. Second, the prior methods do not have a simple way to select a large group of clients, schedule a one-time or recurring configuration data change, and then uniformly apply the configuration data change to the large group of clients. In particular, managing clients and performing configuration data changes to a large group of clients require many manual steps. Third, the prior methods do not attempt to keep track of an operation of a particular client. Therefore, changing configuration data in previous methods often involves manually applying configuration data changes to a large group of clients, when in reality a smaller group of clients should have been affected by the changes. This creates inconsistency in managing configuration data and further wastes valuable network resources.
Another disadvantage of the prior methods is the difficulty in keeping track of a configuration state of a particular client. Specifically, there lacks a method that identifies the clients in a network environment, their configuration states, and their operations. Additionally, the prior methods do not provide consistent data versioning for configuration data and thus cannot identify and record a particular configuration state as a “complete” configuration state in order to support rollback or roll-forward of client configuration state. For example, when a change in configuration data adversely affects the behavior of a client, it is difficult and expensive to change the configuration state of the client to a previous “complete” configuration state. Adding to the difficulty to rollback or roll-forward a configuration state is a lack of support for auditing a sequence of changes to configuration data. This further results in inabilities to track changes that cause system instability, to monitor client performance, and to prevent conflicting configuration data changes.
Yet another disadvantage of the prior methods is the ineffectiveness in controlling access to configuration data of a particular client. The prior methods do not have an effective authorization system for controlling access to configuration data. Usually, an individual either is allowed to access and change configuration data or is denied access to the configuration data. As such, the prior methods cannot provide flexibility in allowing an individual to change/override, add/remove, and view configuration data of a client or group of clients.
The prior methods also lack knowledge of the rotation status of the servers/services in the system. Without knowing such rotation status, more than expected servers may be taken out of rotation for deployment and/or maintenance, which causes reduction of expected service availability. Further, the prior methods lack a common architecture to define how configuration data would be managed for a number of clients. There is not an integrated environment or object model that network administrators could use to write scripts to automate operational tasks. In particular, there is no scriptable application programming interface (API) or graphical user interface (GUI) that enables the majority of configuration data management to be conducted through a single interface. Also, the previous methods do not provide storage of hierarchical data that supports object sub-classing and object property inheritance and do not have a storage standard and metadata to describe stored data. Furthermore, the prior methods lack a cache system that is directly available to individual clients. This means that in the previous methods, some clients may be forced to build different sub-caches to store configuration data in different formats compatible with the sub-caches. This further causes waste of network resources, inconsistent storage formats, and inefficiency in managing configuration data.
Accordingly, a solution that seamlessly manages configuration data across different clients is desired to address one or more of these and other disadvantages.